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ABSTRACT 

LT  General  Buchholz,  the  J6  director  for  Command,  Control, 
Communications,  and  Computer  Systems,  initiated  the 
Network  Warfare  Simulation  (NETWARS)  program  in  1996. 
This  was  in  response  to  concerns  that  C4ISR  networks  and 
systems,  when  exposed  to  full  operational  loading  and 
unanticipated  effects,  may  be  susceptible  to  performance 
degradation  and  failure.  The  objective  of  the  NETWARS 
program  is  to  provide  a  simulation  environment  that  allows 
the  end  user  to  conduct  communications  burden  analyses, 
perform  communication  contingency  planning  and  assess  the 
performance  of  emerging  communications  technology.  A  key 
component  to  the  success  of  NETWARS  is  service 
involvement.  The  services  are  providing  the  entities,  traffic 
loading,  networks/links,  movement  characteristics,  and 
equipment  models  to  be  manipulated  by  the  NETWARS 
toolkit.  This  paper  describes  the  Navy  data  development 
efforts  in  all  of  these  categories,  and  also  discusses  the  long¬ 
term  goals  in  anticipation  of  supporting  other  Navy/DOD 
M&S  programs. 

1.  INTRODUCTION 

The  goal  of  NETWARS  [6]  is  to  provide  a  Joint  Task  Force 
(JTF)  simulation  environment  that  allows  the  end  user  to 
determine  bottlenecks  in  the  military  communications 
infrastructure  and  evaluate  emerging  communications 
technologies.  This  is  accomplished  through  the  development 
of  a  NETWARS  toolkit,  comprised  of  a  front-end  graphical 
user  interface,  and  a  back-end  comprised  of  the  OPNET 
simulation  environment.  The  graphical  front  end  allows  the 
user  to  create  JTF  scenarios.  This  entails  the  specification, 
on  a  world  map,  of  the  entities  involved  in  the  simulation, 
their  movement,  communications  devices  and  the  networks 
and  links  utilized.  The  output  of  the  front  end  is  an  ASCII 
Simulation  Description  File  (SDF)  that  is  submitted  to  the 
OPNET  environment  for  simulation  (Figure  1).  Each  service 
is  responsible  for  providing  simulation  specific  data,  such  as 
the  entities  involved  in  the  scenario,  their  movement, 
communications  devices  located  on  those  entities,  networks 
and  links  utilized,  traffic  flowing  in  and  out  on  those 
network/links,  and  finally  models  of  the  communications 
devices. 

This  paper  describes  the  Navy’s  data  collection  and 
development  efforts  in  these  areas  in  support  of  NETWARS. 
In  section  2  we  provide  a  brief  overview  of  the  data  needed 
by  NETWARS.  In  section  3,  we  describe  the  shortfalls 
within  the  current  “de-facto”  Navy  database  of 


communications  traffic,  and  the  inability  to  fully  utilize  it  for 
NETWARS. 
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Figure  1:  NETWARS  Architecture 

In  sections  4  &  5,  we  describe  the  status  of  the  Navy  in 
obtaining  NETWARS  simulation  data  with  regard  to  the 
planned  studies,  as  well  as  provide  a  short  and  long-term 
approach  for  continually  providing  updated  data.  In  section 
6,  we  discuss  the  long  term  Navy  vision  in  order  to  provide 
the  capability  of  supporting  Navy/DOD  M&S  programs  in 
need  of  similar  data.  In  section  7,  we  provide  a  brief 
summary  and  conclusions. 

2.  NETWARS  DATA  NEEDS 

The  NETWARS  program  has  requested  each  service  to 
provide  specific  simulation  data.  The  NETWARS  front  end 
is  responsible  for  manipulating  this  data  into  a  form  that  is 
“compatible”  with  the  OPNET  simulation  engine.  The  front 
end  allows  the  user  to  specify  the  entities  involved  in  the 
simulation  (e.g.,  LHD  ship)  the  Operational  Facilities,  or 
OPFACS,  co-located  on  the  entities  (e.g..  Fire  Support 
Coordination  Center  FSCC),  system  equipment  (i.e.  SE)  used 
by  the  OPFACS  (e.g..  AN-WSC  3),  networks  and  links 
connected  to  the  SE,  and  finally  the  traffic/messages  (i.e.. 
Information  Exchange  Requirements  or  lERs)  sent  out  on  the 
networks.  The  front  end  also  allows  the  user  to  specify 
movement  trajectories  for  the  entities  as  well  as  velocity  to  be 
executed  during  the  course  of  the  simulation.  Once  a 
scenario  has  been  constructed  in  the  front  end,  it  is  passed  to 
the  OPNET  simulation  engine  for  evaluation.  The  Navy  is 
working  to  provide  entities,  OPFACS,  SEs,  networks  and 
links,  and  lERs  for  the  upcoming  NETWARS  studies. 
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Figure  2:  Plan  of  Action  for  Navy  NETWARS  Support 


3.  SHORTFALLS  IN  NAVAL  ARCHITECTURE 
DATABASE  (NAD) 

The  Naval  Architecture  Database  (NAD)  [5]  has  been 
developed  by  SPAWAR  051  and  is  the  “de-facto”  standard 
that  implements  the  Naval  C4ISR  Operational,  Systems  and 
Technical  Architectures.  The  NAD  does  have  some  of  the 
structure  to  support  the  data  necessary  for  NETWARS; 
however,  certain  key  attributes  are  either  missing  or  are 
vague.  A  review  of  the  NAD  revealed  several  deficiencies. 
The  NAD  does  not  contain  the  relationship  between  System 
Equipment  (SE)  and  Operational  Facilities  (OPFACS). 
OPFACS  are  representations  of  a  grouping  of  SE’s,  intra- 
nodal  connections  and  operational  behaviors  that  are  capable 
of  movement.  Multiple  OPFACS  can  reside  within  the  same 
vessel  or  shore  site.  The  NAD  only  contains  descriptions  of 
which  OPFACS  reside  on  different  ships  and  provides  a 
description  of  SE  types.  The  NAD  does  contain  the  lER’s, 
however,  critical  values  and  fields  are  either  vague  or  non¬ 
existent.  For  example,  the  NAD  leaves  out  the  following 
fields: 

•  urccode, 

•  producingecheloncode, 

•  consumingecheloncode, 

•  application_name_prod_code, 

•  applicationnameconscode. 

The  lER  attributes  of  frequency  and  size  are  often  qualitative. 
For  instance,  the  frequency  values  are  defined  as  periodic, 
continuous  and  as-needed.  The  volume  size  values  are 
defined  as  high,  medium  or  low.  Clearly,  these  are  not 
sufficient  for  a  detailed  NETWARS  simulation.  In  addition, 
the  NAD  does  not  specify  the  protocols  and  system 
interconnect  information  that  is  essential  to  model  SE  to  SE 
connectivities. 

In  spite  of  the  shortcomings  of  the  NAD,  certain  information 
was  obtainable.  Specifically,  the  NAD  was  used  to  obtain 
"operational-level"  type  information  such  as  OPFAC-to- 
OPFAC  communication  (i.e.,  which  OPFACS  communicate 
with  each  other),  and  also  the  OPFACS  contained  on  the 
Navy  ships.  One  of  the  goals  of  the  Navy  is  to  formulate  a 


plan  of  action  to  integrate  the  data  needed  by  NETWARS 
into  the  NAD.  However,  the  data  must  be  validated  before 
being  included  in  the  NAD.  SPAWAR  051  will  handle  this 
validation  process.  The  entire  process  can  be  seen  in  Figure 
2. 

Since  an  in-depth  analysis  of  the  NAD  revealed  several  key 
deficiencies,  the  Navy  NETWARS  team  met  to  discuss  a 
long-term  strategy  to  obtain  the  data  needed  by  future 
NETWARS  scenarios. 


4.  lER  SHORT  AND  LONG  TERM  APPROACH  - 
NAVY  STATUS 

The  Navy  has  chosen  to  develop  short  term,  as  well  as  long 
term  plans  for  data  development.  The  motivation  for  this 
decision  is  so  that  NETWARS,  and  other  programs  like  Joint 
Tactical  Radio  System  (JTRS)  [1],  project  milestones  and 
timelines  are  met,  while  at  the  same  time  the  long  term 
resources  and  tasks  are  on  track  so  that  detailed  data  can  be 
collected  and  formally  verified  and  validated.  For  example,  a 
short-term  solution  might  be  to  obtain  only  those  lER 
attributes  that  will  at  the  very  minimum  allow  a  simulation  to 
occur.  These  attributes  would  include  producing  OPFAC, 
consuming  OPFAC,  size  of  the  lER  generated  by  the 
producing  OPFAC  and  sent  to  the  consuming  OPFAC,  and 
frequency  of  the  lER  sent  by  the  producing  OPFAC  to  the 
consuming  OPFAC.  The  longer-term  goal  would  be  to  obtain 
other  lER  attributes,  such  as  producing/consuming  echelon 
code,  trigger  events,  threading  events,  and  task-to-lER 
relationships.  The  types  of  lER’s  to  be  collected  include 
voice,  data  and  VTC.  Table  1  lists  the  short  and  long-term 
approaches  for  lER  data  collection. 

Table  1 :  lER  Short  and  Long  Term  Plan  of  Action 


Short  Term 

Long  Term 

Data  lER 

•  Personal  Interviews  (Phibgru) 

•  Ship  Logs 

■  NOAC 

•  DERA  (JIFM) 

•  TIRA 

•  Ship  Logs 

Voice  lER 

•  HDD  Parameterization 

•  Personal  Interviews  (Phibgru) 

•  Ship  Logs 

•  UCLA  Work 

•  Ship  Logs 

VTC  lER 

Combination  of  Above 

Combination  of  Above 

Since  our  presentation  at  OPNETWORK  2000  last  year,  we 
have  developed  a  systematic  approach  for  collecting  lER  data 
in  a  hierarchical  fashion.  We  start  with  the  warfare  area,  then 
proceed  to  the  scale/intensity  of  the  conflict,  phase  of 
operation,  specific  mission/operation  within  that  phase,  the 
Universal  Naval  Tactical  List  (UNTL)  tasks  that  are 
associated  with  mission/operation  as  well  as  associated 
conditions  and  standards  that  apply  for  that  UNTL  task,  and 
finally  the  lER’s  associated  with  this  entire  hierarchy.  This  is 
seen  in  figure  3  below. 

This  approach  provides  a  logical  and  systematic  mechanism 
for  lER  collection,  and  all  lER  data  that  is  collected  will  be 
mapped  to  this  approach,  including  all  short  and  long-term 
plans.  We  have  had  a  preliminary  discussion  with 
Amphibious  Group  2  (PHIBGRU2)  communications  officers 
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and  staff,  and  have  received  positive  feedback  regarding  this 
approach.  Moreover,  we  have  begun  collecting  lER  data 
through  interviews  with  PHIBGRU2  staff 


Figure  3:  lER  data  collection  approach. 

With  reference  to  the  above  figure,  our  initial  warfare  area  is: 

•  Amphibious  Warfare  (AMW) 

•  scale/intensity  corresponding  to  “low” 

•  phase  corresponding  to  “Assauh”, 

•  Missions  corresponding  to  Destruction  Fire 
Missions,  Neutralization  fire  missions,  harassing  fire 
missions,  interdiction  fire  missions  illumination  fires 
and  suppression  fires  as  well  as  screening  and 
obscuration  fires. 

•  Each  of  these  missions  correspond  to  UNTL  task 
corresponding  to  NTA  3:  Employ  Firepower. 

Furthermore  we  have  also  begun  collecting  data  for: 

•  Warfare  area  corresponding  to  Strike  Warfare 
(STW).  Specifically,  our  initial  focus  is  on  lER’s 
that  pertain  to  Close  Air  Support  (CAS). 

•  Again  we  have  chosen  a  scale/intensity  of  “low”. 

•  The  phase  is  “execution”, 

•  The  missions  are  Artillery  Air  Spotting,  BHA/BDA, 
Coordination  and  Terminal  Control  of  CAS  Assets, 
NSFS  Air  Spotting,  Radio  Relay  for  the  Tactical  Air 
Control  Party,  and  Visual  Reconnaissance. 

•  Again,  we  have  mapped  each  of  the  missions  to  their 
corresponding  UNTL  tasks. 

Each  of  the  missions  were  collected  from  unclassified  Naval 
Warfare  Publications  (NWP).  Naval  Warfare  Publications 
(NWP)  contains  doctrine  and  tactics,  techniques,  and 
procedures  (TTP)  for  the  employment  of  naval  forces.  The 
NWP  hierarchy  provides  a  framework  for  naval  doctrine  and 
TTP  that  follows  the  Joint  Publication  structure. 

Tactics  are  the  employment  of  units  in  combat  or  the  ordered 
arrangement  and  maneuver  of  units  in  relation  to  each  other 
and/or  the  enemy  in  order  to  use  their  full  potential.  The 
target  audience  is  commanders  of  units  to  which  the  tactics 
apply,  and  their  immediate  superiors  in  command. 


Techniques  describe  employment  of  specific  components  and 
systems  of  ships  or  aircraft.  They  are  generally  written  for 
watch  supervisors  and  operators. 

Procedures  are  instructions,  often  defailed,  for  operation  of 
specific  systems  and  equipment.  Procedures  are  often  more 
rigid  and  directive  than  other  levels  of  tactical  guidance,  due 
to  the  technical  limits  of  weapons,  ships,  aircraft  and  other 
equipment.  Procedures  are  written  for  equipment  or  system 
operators. 

The  principle  means  for  disseminating  TTP  to  the  Navy  is 
through  NWPs.  NWPs  disseminate  information  on  a  broad 
scale  from  top-level  doctrine  to  operational  level  tactics  and 
eventually  down  to  procedural  NWPs,  which  discuss  the 
operation  of  specific  systems. 

Although  the  NWP’s  provide  a  good  foundation  for  validated 
missions/operations,  this  data  is  somewhat  outdated.  During 
our  visits  with  PHIBGRU2,  we  realized  that  certain  missions 
were  renamed  or  dropped  altogether  in  favor  of  others. 

One  note  worth  mentioning  is  the  fact  that  we  have  not  yet 
begun  capturing  the  conditions  under  which  the  lER’s  apply 
or  the  standards  to  which  they  must  achieve  success. 
Conditions  exist  in  the  areas  of  “physical  environmenf’, 
“military  environmenf’,  and  “civil  environmenf’.  As  an 
example,  several  conditions  from  “physical  environmenf’ 
under  which  lER’s  are  valid  include: 

•  Terrain  elevations 

o  Very  High  (>  10,000  ft).  High  (6,000  to 
10,000  ft).  Moderately  High  (3,000  to 
6,000  ft).  Moderately  Low  (1,000  to  3,000 
ft),  low  (500  to  1,000  ft)  and  Very  low  (, 
500  ft). 

•  Electromagnetic  Effects 

o  Extensive,  minor  or  none 

•  Humidity 

o  Very  low  (<10%),  Low  (10  to  50%), 
Moderate  (50-75%)  and  High  (>75%) 

The  standards  are  tied  to  specific  UNTL  tasks.  For  example, 
for  NTA  3.0  (Employ  Firepower),  a  few  examples  of 
standards  for  success  include 

•  Percent  of  high  priority  targets  successfully  attacked, 

•  Percent  of  actual  weapons  used  compared  to 
projected. 

The  lER  is  a  function  of  conditions  and  standards.  Capturing 
conditions  and  standards  for  lERs  will  be  an  area  of  future 
interest,  as  this  will  take  considerable  investment  of 
resources.  Additionally,  data  that  helps  satisfy  the  long-term 
lER  goals  (such  as  threading,  trigger  events,  etc.)  are  being 
collected  whenever  possible.  The  data  collected  to  date  has 
been  provided  to  the  NETWARS  program  for  inclusion  in 
their  studies. 

In  addition  to  interactions  with  PHIBGRU2,  we  have 
collected  lER  data  through  the  Fleet  Battle  Experiment  India 
(FBE-I)  exercises.  We  are  coordinating  with  Navy  Warfare 
Development  Command  at  Patuxent  River  to  collect  SNMP 
data  for  the  following  systems:  PTW-I-,  GCCS-M  and  LAWS. 
The  mission  area  for  which  data  will  be  collected  is  Time 
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Critical  Strike,  and  will  be  integrated  with  the  data  already 
collected  through  PH1BGRU2  interviews. 

The  Network  Operations  Analysis  Capability  (NOAC)  was 
briefly  described  in  [9]  and  more  information  can  be  found  in 
[2].  NOAC  supports  network  analysis  by  providing  actual 
data  as  inputs  to  analytical  tools. 

The  Defense  Engineering  and  Research  Agency  (DERA)  in 
the  UK  is  also  involved  in  several  programs  dealing  with  the 
collection  of  lER  data.  One  specific  program  is  called  the 
Joint  Information  Flow  Model  (JIFM).  JIFM  was  briefly 
described  in  [9].  DERA  is  also  developing  a  simulation 
environment  called  the  Information  and  Network  Simulation 
and  Evaluation  Tool-set  (INSET).  The  relationship  between 
JIFM  and  INSET  can  be  seen  in  Figure  4. 

The  Tool  for  Interoperability  Risk  Assessment  (TIRA)  is  a 
SPAWAR  effort,  leveraging  work  from  the  Distributed 
Engineering  Plant  (DEP)  and  Joint  DEP.  TIRA  was  briefly 
described  in  [9].  TIRA  provides  risk  assessment  and  analysis 
with  regards  to  the  interoperability  of  joint  and  Navy  systems. 

The  Hierarchical  Data  Dictionary  (HDD)  represents  a 
hierarchical  organization  and  description  of  the  information 
(lER’s)  in  the  NAD.  In  other  words,  each  lER  in  the  NAD  is 
categorized  according  to  the  HDD.  The  HDD 
parameterization  technique  involves  the  determination  of  the 
lER  size  and  lER  frequency-driving  parameters  for  each  of 
the  HDD  entries  associated  with  the  lER’s.  This  is  very 
similar  to  the  approach  DERA  is  undertaking  with  JIFM.  The 
benefits  of  this  approach  are  that  there  are  far  fewer  HDD 
entries  than  there  are  lERs  in  the  NAD.  Also,  it  has  the 
advantage  that  the  lERs  are  developed  in  operator  terms. 


CIS  Operation  Support  Measure 


Business  Model 


Business  Assessment 

Processes  Hierarchy  Process 
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Figure  4:  JIFM  and  INSET 


5.  COMMUNICATIONS  MODELS  -  NAVY 
STATUS 

The  NETWARS  program  provides  an  M&S  capability  to  the 
Commanders-in-Chief  (CINCs).  The  NETWARS  toolkit 
provides  a  robust  capability  to  analyze  the  impact  of  new 
technology  on  battle  group  communications  and  the 
performance  of  large-scale  communication  environments 
such  as  in  a  JTF.  The  NETWARS  analysis  requirements 
highlight  the  need  for  models  with  varying  levels  of  fidelity 
and  aggregation  [3].  The  ability  to  interface  a  variety  of 
models  with  differing  levels  of  fidelity  has  several  technical 


challenges.  For  example,  in  order  to  determine  the  impact  of 
new  radios  on  the  communication  performance  of  a  JTF,  it 
may  be  necessary  to  insert  a  high  fidelity  model  of  a  radio 
into  a  low  fidelity  environment.  In  previous  NETWARS 
demonstrations,  this  procedure  resulted  in  very  long  run-times 
for  the  simulations  Additional  problems  include  interfacing 
models  of  different  fidelities,  as  well  as  insuring  that  the  low 
fidelity  models  provide  the  necessary  lERS  and  MOE’s  and 
mop’s  that  are  required  of  the  simulation.  This  issue  of 
multi-resolution  modeling  has  been  a  concern  in  the  M&S 
community. 

The  Navy  has  recently  developed  an  innovative  approach  that 
resolves  problems  through  multi-resolution  modeling.  The 
Navy’s  approach  utilizes  functional  models  and  integrated 
analytic  techniques  [3]  [4].  This  approach  has  been  presented 
at  previous  J6  technical  working  groups  and  resulted  in 
positive  collaboration  with  the  Air  Force,  Marines  and  Army. 
In  addition,  these  functional  models  will  enhance  the  Naval 
Space  Command  Modeling  initiatives  in  analyzing  bandwidth 
requirements  for  an  ARG  and  BG  for  the  year  2005.  These 
Navy-specific  models  validated  the  multi-resolution  approach 
and  modeling  standards  methodologies. 

The  architecture  of  these  models  was  produced  to  reduce 
simulation  run-time  and  provide  a  mechanism  to  run  low 
fidelity  with  high  fidelity  models.  The  key  to  reducing  the 
run-time  was  an  implementation  of  hybrid  models  that 
included  equations  or  curves  of  network  performance.  With  a 
discrete  time  simulation  engine,  much  processing  is  required 
to  track/process  all  events  created  by  the  interaction  of 
models.  The  Navy  had  successfully  deployed,  in  previous 
work,  a  method  of  reducing  the  number  of  events,  which  in 
turn  significantly  reduced  simulation  run-time.  Additional 
functions  are  also  included  in  this  work  to  further  reduce  run 
time,  such  as  centralizing  network  switching/routing.  This 
work  also  provides  an  alternate  to  OPNET’s  traditional 
pipeline.  Models  of  communication  links  provide  a  medium 
that  has  attributes  to  account  for  effects  of  propagation  [2]. 

5.1  Modeling  Approach 

The  NETWARS  program  requires  JTF  simulation  scenarios 
with  up  to  20,000  nodes.  In  order  to  accommodate 
manageable  run-time  requirements  of  scenarios  with  large 
numbers  of  nodes  and  to  produce  MOEs  and  MOPs  of 
appropriate  accuracy,  performance  functions  are  used  where 
appropriate  to  compute  the  performance  of  simulated  device 
and  entity  models.  A  performance  function  is  a  mathematical 
function  that  computes  the  specific  performance  value(s) 
based  on  the  current  operating  point  in  the  operating  range  of 
a  device  or  entity.  Examples  of  performance  results  include 
message  delay  and  loss  across  a  point-to-point  link,  message 
latency  through  a  switch,  and  access  delay  through  a  media 
controller.  Performance  functions  are  to  be  based  on 
analytical  results,  field  exercises  and  tests,  and  more  detailed 
and  focused  simulation  studies  of  devices.  The  structures  of 
performance  functions  include  mathematical  equations  and 
table  look-ups.  The  modular  development  of  models  allows 
for  the  enhancements  and  updates  of  performance  functions 
as  required.  Figure  5  provides  an  illustration  of  the  use  of 
performance  functions  in  the  calculation  of  performance 
results  for  simulated  device  models. 
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Figure  5:  Performance  Function  Approach 

The  MAC  function  library  was  designed  to  model  the  effects 
of  shared  communications  media  on  message  transmissions. 
These  effects  include  message  delays  and  losses.  The  MAC 
function  library  utilizes  performance  functions  to  characterize 
these  effects  by  including  both  the  transmission  medium  and 
the  contention  protocol  in  a  single  link  model  entity. 

The  modularity  and  flexibility  of  these  functions  facilitate  the 
modeling  of  a  variety  of  serial,  bus  and  wireless  link  types. 
Link  model  performance  and  operation  are  derived  from 
performance  functions,  as  illustrated  in  Figure  6.  Message 
delays  and  loss  effects  are  determined  from  performance 
functions  that  are  based  upon  several  link  conditions.  Link 
conditions  may  consist  of  several  factors,  such  as  the  number 
packet  arrivals  per  unit  time  or  the  number  of  active  traffic 
sources,  or  taps,  on  a  link. 


Figure  6:  MAC  Layer  performance  function 

Network  routing  provides  the  capability  for  message  delivery 
among  nodes  across  a  network.  Network  elements,  such  as 
routers  and  switches,  typically  utilize  routing  protocols  to 
build  and  update  routing  tables  in  a  distributed  fashion.  A 
centralized  process  that  facilitates  the  modeling  of  these 
routing  protocols  has  been  developed  for  the  Navy  Battle 
Group  model  suite.  This  is  described  further  in  [9]. 

One  of  the  key  inputs  to  the  models  is  data  in  the  form  of 
lER’s.  The  lER  data  drives  traffic  generation  within  the 
simulation.  The  models,  regardless  of  their  fidelity,  must 
support  the  lER’s  required  for  determining  the  MOE’s  and 
mop’s.  This  generally  requires  detailed  lER  information  to 
have  been  obtained.  In  fact,  the  simulation  is  often  only  as 
accurate  as  the  lER  data  that  is  fed  into  it,  thus  the  need  for 
detailed,  accurate  lER  data  is  great.  As  the  collected  lER 
data  becomes  more  complete,  the  results  obtained  from  the 
models  will  become  more  accurate  and  dependable. 


5.2  Navy  Carrier  Battle  Group 

The  modeling  approach  described  above  was  implemented  in 
the  development  of  Navy  NETWARS  models.  At  the 
Network  editor  layer  of  OPNET,  models  of  each  class  of 
ships  in  a  traditional  battle  group  were  developed  by 
populating  an  appropriate  set  of  C4ISR  systems  that  are 
provided  by  the  Navy  system  OPNET  palette.  At  the 
link/physical  layer,  each  ship  is  provided  RF  resources  based 
on  Operational  Navy  communication  plans.  Additional 
details  on  the  construction  of  an  Amphibious  Readiness 
Group  and  Carrier  Battle  Group  are  available  in  references 
[7]  and  [8]. 

The  Navy’s  modeling  approach  provided  significant 
reduction  in  I'un-times  that  in  turn  provided  Navy  analysts  the 
capability  to  perform  multiple  “what-if’  type  experiments. 
Recently,  Joint  Maritime  Systems  Analysis  Center  (JMSAC) 
analysts  studied  the  performance  of  a  fairly  complex  system, 
which  in  past  simulation  studies  were  difficult  to  perform  due 
to  lengthy  run  times. 

The  models  are  currently  being  used  and/or  evaluated  by: 

•  Assistant  Secretary  of  Navy  (RDA)  Chief  Engineer 
(ASN  RDA)  Bandwidth  Assessment  Team  -  the 
C4ISR  communications  models  were  used,  and 
assessed,  in  how  well  they  support  Time  Critical 
Strike  missions. 

•  Naval  Space  Command  (satellite  communication 
division)  -  They  are  performing  an  assessment  of 
existing  satellite  communication  resources 
supporting  a  small  conflict  to  a  major  theater  of  war. 
The  communications  models  described  here  are  used 
as  a  baseline  for  comparison. 

•  SPAWAR  PMW-187  -  Naval  Sensor  System 
Initiative  (NAVSSI)  used  the  Carrier  models  to 
determine  the  added  performance  of  fielding  IT-2L 

•  High  Performance  Computing  Management  Office 
for  Force  Modeling  and  simulation  is  using  the 
models  to  port  into  another  simulation  engine 
(sequential  and  parallel)  for  better  run-time 


6.  LONG  TERM  NAVY  VISION 

The  long-term  vision  within  the  Navy  NETWARS  working 
group  is  to  eventually  incorporate  the  aforementioned  data 
into  the  NAD  (or  at  least  an  interim  database  until  V&V  can 
be  done).  Over  the  course  of  the  year,  discussion  within  the 
Navy  NETWARS  working  group  has  brought  forth  a  vision 
to  integrate  many  of  the  Navy  databases  into  one  "logical" 
database  that  is  both  CADM  compliant,  as  well  as  compliant 
with  the  DOD  Data  Architecture  (Figure  7).  Discussions  are 
on  going  with  N6M,  SPAWAR  051,  NRL  and  Silver  Bullet 
Solutions  Incorporated  (SBSI). 
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Figure  7:  Long  Term  Navy  Vision 

7.  SUMMARY  AND  CONCLUSIONS 

In  the  category  of  lER  collection,  we  plan  to  continue  with 
the  amphibious  warfare  area  (i.e.,  the  missions  associated 
with  AJyiW)  as  well  as  in  STW.  This  should  provide 
sufficient  validated  data  for  the  NETWARS  studies.  Our 
efforts  will  also  focus  on  including  condition/ standards 
associated  with  the  lERs,  as  well  as  triggering  effects, 
threading,  etc.  The  Navy’s  strategic  plan  for  collecting 
detailed  lER’s  will  support  many  analysis  requirements 
including  NETWARS. 

The  Navy’s  extensive  experience  in  network  modeling  and 
simulation  has  resulted  in  an  innovative  approach  to  handling 
the  multi-resolution  objectives  of  NETWARS.  This 
technology  was  used  in  the  development  of  C4ISR 
communication  systems  for  an  ARG.  In  addition,  models  of  a 
Battle  Group  are  being  built  for  future  NETWARS  studies. 
In  anticipation  of  studies  that  are  being  conducted  within 
NETWARS,  the  Navy  is  cumently  taking  models  through  a 
formal  V&V  process.  This  will  ensure  that  each  system 
(including  protocols),  lER  and  transmission  medium  is 
accurately  reflected. 
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